home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000141_owner-urn-ietf _Thu Oct 31 14:13:30 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA17756 for urn-ietf-out; Thu, 31 Oct 1996 14:13:30 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA17751 for <urn-ietf@services.bunyip.com>; Thu, 31 Oct 1996 14:13:28 -0500
  3. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA27155  (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:13:25 -0500
  5. Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA04704; Thu, 31 Oct 1996 12:13:18 -0700 (MST)
  6. Message-Id: <2.2.32.19961031192104.006e5d70@acl.lanl.gov>
  7. X-Sender: rdaniel@acl.lanl.gov
  8. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. Date: Thu, 31 Oct 1996 12:21:04 -0700
  12. To: Terry Allen <tallen@fsc.fujitsu.com>, urn-ietf@bunyip.com
  13. From: Ron Daniel <rdaniel@acl.lanl.gov>
  14. Subject: Re: [URN] HTTP resolution protocol
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Ron Daniel <rdaniel@acl.lanl.gov>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Thus spoke Terry Allen (at least at 10:37 AM 10/31/96 -0800)
  21. >A few comments, mostly re coordination with the Framework document:
  22. >
  23. >| 3.1  N2L (URN to URL):
  24. >| The request is encoded as above. The URL MUST be returned in a Location:
  25. >| header for the convienience of the most common case of wanting the resource.
  26. >| A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the
  27. >| 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily)
  28. >| status code unless the resolver has particular resons for using 301
  29. >| (moved permanently) or 304 (not modified) codes.
  30. >
  31. >It would be nice to have a brief explanation of why these are
  32. >the right responses, perhaps recapping what will be in the
  33. >Framework document.
  34.  
  35. No commitments on this one, but I will see what we can do.
  36.  
  37. >|                Simple format for returning multiple URLs
  38. >| 
  39. >| [Do we need to have a continuation character for *very* long lines? 
  40. >|  I tend to think not.]
  41. >
  42. >Might be useful; there will be a significant proportion of long lines.
  43.  
  44. Right, but that does not mean that the long lines have to be broken.
  45. I am unaware of any line length limitation for text/plain bodies.
  46. If we don't break the lines, things are simpler.
  47.  
  48. >| 3.4  N2Rs (URN to Resources):
  49. >| This resolution service returns multiple instances of a resource,
  50. >| for example, GIF and JPEG versions of an image. The judgment about
  51. >| the resources being "the same" resides with the naming authority that
  52. >| issued the URN.
  53. >
  54. >All the instances that suit the Accept info the client has sent?
  55. >Does that leave us with nothing between asking for one instance
  56. >(N2R) and all (N2Rs), or is there some way to quality the request
  57. >so that one receives no more than, say, 13 instances?  (Happy
  58. >Halloween!)
  59.  
  60. I will add some words to the effect that the resolver MAY restrict
  61. the resources returned to those that match the Accept: header.
  62.  
  63. >| 3.6  N2Ns (URN to URNs):
  64. >| ------------------------
  65. >| 
  66. >| While URNs are supposed to identify one and only one resource, that
  67. >| does not mean that a resource may have one and only one URN. For
  68. >| example, consider a resource that has something like
  69. >| "current-weather-map" for one URN and "weather-map-for-datetime-x" for
  70. >| another URN. The N2Ns service request lets us obtain lists of URNs that
  71. >| are believed equivalent at the time of the request. As the weathermap
  72. >
  73. >The example implies, "lists of URNs that are believed to name equivalent
  74. >resources at the time of the request", which agrees with the language
  75. >in the next para.
  76.  
  77. Right. I will change the wording to be more precise.
  78.  
  79. >| 3.8  L2Ls (URL to URLs):
  80. >| ------------------------
  81. >| 
  82. >| The request is encoded as described above. The result is a list of
  83. >| all the URLs that the resolver knows are associated with the resource
  84. >| located by the given URL. It is returned in a text/plain body encoded
  85. >| as described above.
  86. >
  87. >"Associated" is awfully broad.  The Framework document will clear up
  88. >what associations are intended, right?
  89.  
  90. Using "associations" was a mistake on my part. The intent here is that
  91. we return the locations of equivalent resources, analogous to the N2Ns
  92. request.
  93.  
  94. Ron Daniel Jr.                       email: rdaniel@lanl.gov
  95. Advanced Computing Lab               voice: +1 505 665 0597
  96. MS B287                                fax: +1 505 665 4939
  97. Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
  98. Los Alamos, NM, USA  87545    obscure_term: "hyponym"
  99.